Appl. No. 09/823,167 

Amendments to the Specification 

Please replace the paragraph at page 8, line 20 - page 9, line 3 with the following 
replacement paragraph: 

Referring to FIG. 2, an exemplary device for creating, storing, transmitting and 
receiving sound messages and/or personal sound identifiers is shown. As shown in FIG. 
2, the device is a type of Personal Digital Assistant (PDA) 100. It is known that PDAs 
come in a variety of makes, styles, and configurations and only one out of the many 
makes, styles and configurations is shown. In one embodiment of the present invention, 
PDA 100 includes a includ e s a low profile box shaped case or housing 110 having a front 
face 1 14 extending from a top end 1 18 to a bottom end 122. Mounted or disposed within 
front face 1 14 is a display screen 126. Positioned proximate to_bottom end 122 are 
control buttons 132. Display screen 126 may be activated and responsive to a stylus, 
control pen, a finger, or other similar facility, not shown. Disposed within housing 1 10 is 
a processor coupled with memory such as RAM, a storage facility and a power source, 
such as rechargeable batteries for powering the system. The microprocessor interacts 
with an operating system that runs selective software depending on the intended use of 
PDA 12. As used in accordance with the teachings herein, memory is loaded with 
software code for selecting/generating, storing and communicating via sound messages 
and/or personal sound identifiers with one or more other users in the system. 

Please replace the paragraph at page 10, line 19 - page 11, line 5 with the following 
replacement paragraph: 

Referring now to FIGS. 3 and 4, an exemplary method and device is shown for 
creating and transmitting sound messages and/or personal sound identifiers between users 
in the system. As shown in FIG. 3, the user creates a sound message, step 136. A sound 
message may be created by simply s e l e ct e d selecting a sound message from a selection 
of pre-recorded sound messages or sound message may be newly created by a user, such 
as by employing a sound editor utility to construct a sound message. Once a sound 
message is created, the sound message is saved, step 140. Saving may be done locally on 
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a user's personal communicative device by simply saving the sound message with, for 
example, a sound editor utility as a sound file on the device's storage facility. The user 
may then select or create an icon to be associated with the sound message, step 144. The 
icon may be selected from a selection of already existing icons or may be specially 
created by the user via a graphics utility or facility. In other embodiments, an icon may 
be assigned to the sound message automatically. Once an icon is selected/created and is 
now associated with a specific sound message, the user may send the sound message to 
any number of users in the system. To accomplish this, the user may select one or more 
users to send the sound message to, step 148. This may be accomplished, as discussed in 
more detail later herein, such as by selecting one or more user names from a directory of 
users. The user may then transmit the sound message to the selected users by selecting or 
activating the icon associated with the desired sound message, step 152. 

Please replace the paragraph at page 18, line 14 through line 27 with the following 
replacement paragraph: 

Referring to FIG. 6, an exemplary messaging configuration is shown. In this 
embodiment, a message originator or sender 600 sends a message 610 to at least one 
message recipient or receiver 620. Message 610 is send -sent via a message server 630 
which receives message 610 from message sender 600 and provides message 610 to 
message recipient 620. Once message 610 is received by message recipient 61Q620, 
message recipient 620 provides a message acknowledgment or ACK 670 back to message 
sender 600. A message listing 650 may be updated by message sender 650 once the 
ACK 670 is received from message recipient 620 while a message listing 660 may be 
updated by message recipient 620 once message 620 -610 is received. Updating message 
listing 660 by message recipient 620 prevents messages being duplicated, such as in the 
case of where message ACK 670 is not received by message sender 600 and 
consequently, message sender 600 re-sends another copy of message 610 to message 
recipient 620. In such an example, the re-sent message will be compared with the 
message listing by message recipient 620 and will be discarded if the re-sent message has 
already been tagged as being seen, as discussed in more detail later herein. 
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Please replace the paragraph at page 19, line 20 through page 20, line 3 with the 
following replacement paragraph: 

In this embodiment, it is not possible for someone to believe that they said 
something when the other person didn't see it, but it is possible for a recipient to see a 
message while the sender thinks thev^d -thev didn't. This can cause just as much of a 
problem in a conversation. In such a situation, the present invention provides certain 
safeguards to prevent this problem. For example, when a client sends a message, it waits 
to see if it gets an ACK for a predetermined number of seconds, such as, for example, 
anywhere from one to ten seconds. If it does not, it resends the message. It does this as 
many as X times, stopping as soon as it gets an ACK. X may be any number, such as in 
the range of one to fifty, depending on the requirements desired. On the other end, if a 
message arrives that the client has already received, it sends back an ACK but it does not 
re-display the message. In this way, each client properly indicates whether the message 
got through to the other end, but no message will appear multiple times on the recipient's 
screen. It is possible, though, for the messages to appear in a different order on both 
sides. If, for example, the sender sends two messages and the first one is dropped along 
the way, the first message will be resent after an X number of seconds, and it will be 
displayed on the recipient's screen after the first. 

Please replace the paragraph at page 20, line 5 through line 10 with the following 
replacement paragraph: 

With this approach, if someone sees that a message they sent is pending, i.e. in 
gray and it stays pending, i.e. gray, they can be pretty confident that the other person did 
not get the message. This can happen because of a number of situations, such as if the 
sender's connection is poor or because the recipient's connection is poor. To help 
distinguish these cases, cues are provided to the user about their own level or 
connectivity and to let them know if the other person has gone offline, as described in 
more detail later herein. 
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Please replace the paragraph at page 22, line 9 through line 14 with the following 
replacement paragraph: 

To further describe the operation of the present invention, when a client receives a 
message, it responds with an ACK (as it has to do each time) and it checks the sequence 
number and sender ID to see if it's seen this message before. If the client hasn't seen it 
before, it processes it (displays it, plays it, what e v e r etc ). If it has seen it before, the 
message is simply discarded. In either case, it has already sent an ACK back to Client A 
so Client A can stop re-sending it, as may be represented by the following pseudo-code. 

Please replace the paragraph at page 23, line 23 through line 31 with the following 
replacement paragraph: 

There is a situation where the user may not receive the message in accordance 
with the above delivery methodology. For example, if someone sends a message to a 
user immediately after the user leaves their currently active client, i.e. the user's work PC 
for the night, the server is going to send the message to the user's work PC since it 
appears that the work PC is an active client. When the user gets home and either 
becomes active on their home machine, it would be desirable to see the messages that 
were sent to the user at my office since the user left. Otherwise, the message will remain 
unread at the work PC client until, for example, the user gets to work the next morning. 
So in this situation, when the user becomes active on the home client, the server resends 
me-the messages originally sent to the office client. 

Please replace the paragraph at page 25, line 35 through page 26, line 3 with the 
following replacement paragraph: 

Referring to FIG. 7, one embodiment of the present invention is shown. In this 
embodiment, a message is received from at least one message originator destined for at 
least one message recipient, step 700. A pending message indicator is provided for the at 
least one message originator, step 710. It is determined if the message has been received 
by at least one message recipient, step 720, as may be determined in accordance with the 
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descriptions above. The pending message indicator is updated to indicate message 
received, step 730. Updating the message indicator may be performed as described 
e arli e r h e r e in hereinabove, for example, by changing the message indicator from a first 
pending appearance, to a second received appearance as may be evidenced by a color or 
pattern change or other distinguishable appearance change. 
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